Asynchronous communication refers to the transmission of data between two applications that are essentially independent of one another (i.e., the applications are not synchronized). In asynchronous communication, the sending application is free to transmit data at any time regardless of whether the receiving application is ready to receive the transmission. Such asynchronous communication is widely used to transmit data from device to device, system to system, network to network, and combinations thereof where the devices, systems, networks, and so forth are not directly engaged with one another.
The above arrangement is particularly useful in systems that rely on one-to-many relationships because of the greater scalability such relationships afford. One such system is a so-called “publish/subscribe” system where senders (publishers) do not send (publish) messages to specific receivers (subscribers). Rather, publishers publish messages to certain categories without knowledge of the subscribers (if any), and subscribers subscribe to one or more these categories without knowledge of the publishers (if any). The messages are then filtered and delivered to the subscribers based on either the message topic or the message content, or a combination of the two. In topic-based systems, messages are delivered to named logical channels. Subscribers in such topic-based systems receive all messages published to the channels to which they subscribe. The publisher is responsible for classifying the messages. In content-based systems, messages are only delivered to a subscriber if the attributes or content of those messages match constraints defined by the subscriber. The subscriber is responsible for classifying these messages.
FIG. 1 illustrates an example of a publish/subscribe system 100 where a publisher 102 publishes messages to at least one subscriber 104. The messages typically relate to or contain information about certain events that are of interest to the subscriber 104. A message-oriented middleware (MOM) 106 facilitates delivery of the event messages from the publisher 102 to the subscriber 104. The message-oriented middleware (MOM) 106 determines which category the event message belongs to and transmits the message to a message queue 108 for that category. The message queue 108 subsequently delivers the event message to the subscriber 106.
The send-and-forget nature of publish/subscribe systems can be a drawback, however, when one or more subscribers 102 are unable to process the event messages. This typically occurs when a certain system resource 110 (e.g., a server, a database, etc.) needed to process the event messages is unavailable. When this happens, a transaction manager (not expressly shown) rolls back or otherwise reverses the attempted transaction with the system resource 110 and sends the event message back to the message queue 108 for redelivery. The sending back of the event message to the message queue 108 and subsequent redelivery normally takes only a few seconds. Unfortunately, a resource outage often lasts longer than a few seconds so that the redelivery also fails and additional redeliveries ensue. After a certain number N of retries, the event message is backed completely out of the message queue 108 to a backout queue 112 for manual intervention, usually by a system operator 114.
As can be seen from the foregoing, current publish/subscribe models are inefficient at best, particularly where downtime for a required system resource is known beforehand (e.g., due to scheduled maintenance, etc.). Accordingly, what is needed is a more efficient way to handle redelivery of failed messages in publish/subscribe systems in particular and in asynchronous communication systems in general. More specifically, what is needed is a way to automatically delay redelivery of such failed messages to give required system resources a chance to recover.